Tiny change but maybe capitalize it to be consistent with the other descriptions?

I just want to make sure I’m interpreting the modeling correctly.
algorithmProperties.mode is described as a block-cipher mode of operation, whereas gmac and cmac are typically treated as MAC constructions.

Are we intentionally allowing them here as AES variant suffixes (i.e., registry-aligned usage)? If so, would it make sense to slightly broaden the mode description to reflect that?

Alternatively, should these be modeled under primitive: mac (with cryptoFunctions: tag) and keep mode strictly for block-cipher modes?

the meta:enum descriptions for gmac and cmac don’t currently end with a period, while most other entries do. Would you like to align those for consistency?

I just want to make sure I’m interpreting the modeling correctly. algorithmProperties.mode is described as a block-cipher mode of operation, whereas gmac and cmac are typically treated as MAC constructions.

Are we intentionally allowing them here as AES variant suffixes (i.e., registry-aligned usage)? If so, would it make sense to slightly broaden the mode description to reflect that?

Alternatively, should these be modeled under primitive: mac (with cryptoFunctions: tag) and keep mode strictly for block-cipher modes?

I initially hesitated to categorize CMAC and GMAC as 'modes of operation' in the traditional sense. However, NIST SP 800-38D gave me an argument since it states: GCM and GMAC are modes of operation for an underlying approved symmetric key block cipher.

The mode property has become slightly redundant with the naming patterns in 1.7, so I would recommend to give the patterns the priority when creating CBOMs to express the algorithm details.

That makes sense — thanks.